IBIS Macromodel Task Group Meeting date: 15 April 2014 Members (asterisk for those attending): Agilent: * Fangyi Rao * Radek Biernacki Altera: * David Banas ANSYS: * Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Brad Brim * Kumar Keshavan * Ken Willis Scott Huss Ericsson: Anders Ekholm Intel: Michael Mirmak LSI Amaresh Malipatil Dai Xingdong Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Andrey Matvienko Vladimir Dmitriev-Zdorov Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz * Todd Westerhoff * Mike LaBonte Teraspeed Consulting Group: Scott McMorrow * Bob Ross The meeting was led by Arpad Muranyi ------------------------------------------------------------------------ Opens: - Bob: An IBIS-AMI model has been submitted for review,should be discussed. - Arpad: There is an AMI file topic for clarification. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Todd provide BIRD 147 with annotated comments - Todd and Ken had a discussion in lieu of this. - Mike post documents from previous meetings. - Done ------------- New Discussion: IBIS-AMI file for review: - Bob: Li Jun submitted a model from an IC vendor. - I've contacted the company before releasing this. - I can communicate some things the parser finds. - This will be distributed to several EDA companies for review. - Walter: That is not really an IBIS-ATM issue. - Mike: The IC vendor has to request this. - The results probably can not be communicated to Li Jun. IBIS 6.0 issue: - Arpad showed IBIS 6 page 187 - Arpad: There is an error giving the hex code for double quotes. - Also it does not clarify character set for AMI files. - Walter: That is a mistake and should be clarified. - AMI files should use the same character set as IBS files. Backchannel: - Ken: Todd and I were to restate objectives and goals. - Ken showed High Level Backchannel Summary - slide 1 - Ken: SiSoft asked for a larger co-optimization capability. - Backchannel is just part of that. - slide 3 - Ken: The key capability is communicating adjustments back to the TX. - It has to support TX and RX from different vendors. - slide 4: - Ken: There should be minimal churn implementing new protocols. - New keywords should not be required. - slide 5: - (architecture overview) - slide 6: - (flow overview) - slide 7: - Ken: Support for statistical simulation has been incorporated into BIRD 147. - slide 8: - Ken: This was first submitted 3 years ago. - We need an IBIS standard approach for interoperability. - We are willing to consider "bigger picture" proposals from SiSoft. - Todd: This is much more clear. - The diagrams did not show the statistical flow though. - It's not obvious how that would fit in. - Ken: Statistical will not apply to the real hardware anyway. - Walter: I agree with the flows and functionality. - Todd: For statistical we envision the RX finding settings in a one-shot process. - Ken: The RX Init can send settings to TX Init. - Walter: RX Init could implement a time domain simulation within itself. - We should not limit what the RX can do. - Ambrish: We are trying to create a multi-vendor solution. - Walter: I disagree with some of the implementation but not the flow. - Radek: On slide 6 it would be good to address Walter's suggestion for a new API. - It should be properly defined for training. - Walter: Cadence and SiSoft have both implemented co-optimization using what exists. - Here we are agreeing on a way to do it. - You can propose a new method but we do not intend to. - Arpad: Does BIRD 147 need more work? - Walter: I have a presentation? - Walter showed "Backchannel Co-Optimization Requirements" - slide 2: - Walter: TX and RX behaviors can overlap. - For example TX post-cursor and RX CTLE/DFE do the same thing. - A balanced solution requires co-optimization. - slide 3: - Walter: The hardware protocol can be emulated. - This is what BIRD 147 does. - Settings can also be optimized based on performance criteria. - System performance can be verified once settings are found. - BER and operating margin are common measures. - The SerDes settings must result from this. - Ken: #1 and #2 are not exclusive? - Walter: The silicon could optimize using the protocol. - Ken: The model can make any judgment it wants. - Todd: In this context the RX can do whatever it wants. - Kumar: The protocol only specifies communication. - slide 4 - (list of 7 requirements) - Walter: BIRD 147 does not address item #4, what it is optimized to. - There should be limits on tap indexes. - The DLL and AMI to not need to have register mappings, but they should enable it. - All possible combinations of statistical and TD should be supported. - Ambrish: The AMI parameters are not directly tied to the back-channel? - Walter: It would be good to identify AMI parameters that correspond to tap indexes. - Todd: We need a plan to do all of these things. - The training emulation identifies the starting point. - We must specify these things or it will not happen. - Ken: Does slide 4 have requirements for the spec or the tool, or both? - Todd: This is for the spec plus what the tools can do to provide a solution. - slide 5: - (list of flows) - Walter: Statistical co-optimization could be follow by TD co-optimization, then statistical and TD simulation - This should all be in one BIRD. - Ambrish: The 3rd bullet is not clear. - Fangyi: How are optimal taps sent back to the TX? - Walter: In TD it uses GetWave AMI_parameters_out. - Fangyi: How are TX taps passed to the TX in statistical? - Walter: The RX finds tap coefficients. - First the RX knows the TX equalization. - This assumes a trainable TX. - This will have pre and post cursor taps, maybe more post. - The TX may not be capable of using the coefficients from the RX. - Another pass is needed to have the TX make recommendations based on what it can do. - Ambrish: The 2nd and 3rd bullets are in the BIRD. - The rest is a wish list. - We have most of it now. - Walter: The BIRD requires a common protocol. - We believe the TX could be protocol-agnostic. - The protocol would be all in the RX. - There are some things I don't know how to do with BIRD 147. - Todd: We need to step back and look at requirements. - It might not require a big change from what Cadence is doing. - We should look at our two sets of requirements to check the alignment. - Ken: The register settings can be done in AMI Model_Specific. - Walter: Can we look at what I'm proposing? - Todd: We specify some things that vendors don't do. - For example the samples per bit requirement. - Ken: We have put best practice items into cookbooks in the past. - Todd: It hasn't worked well enough. - Ambrish: More regulation is not the answer, we should let the market decide. - Kumar: At best the TX can output coefficients. - The protocol is very device specific. - Todd: We have hope on slide 4 requirement #4. - Ambrish: I think we can do that. - Walter: We are not looking at big changes. - There are only 3 tap parameters to deal with, coefficients, increments, and indexes. - With this BIRD an RX can only send increments. - There should be Reserved_Parameters, not the overhead of a BCI file. - That will require some group to validate BCI files. - Ambrish: How will the RX know how to send the data? - Walter: We only need to identify which parameter is coefficient, increment, and index. - Todd: We seem to have more common ground now. - Bob: Does SiSoft intend to propose replacing BIRD 147? - Walter: I would like a new BIRD without no BCI file. - Todd: We have to discuss this more at SiSoft. ------------- Next meeting: 22 April 2014 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives